Distributed architecture for a telecommunications system

ABSTRACT

A method of call processing includes passing, over a local area network, control signals from a centralized controller to each of a plurality of decentralized processors. The method also includes having each of the plurality of decentralized processors, in response to the control signals, executing decentralized call control functions.

BACKGROUND

[0001] A traditional voice telephone network typically employs acircuit-switched network to establish communications between a senderand a receiver. The circuit-switched network is a type of network inwhich a communication circuit (path) for a call is set-up and dedicatedto the participants in that call. For the duration of the connection,all resources on that circuit are unavailable for other users. AnElectronic Worldwide Switch Digital (EWSD) is a widely-installedtelephonic switch system. Common Channel Signaling System No. 7 (i.e.,SS7 or C7) is a global standard for telecommunications defined by theInternational Telecommunication Union (ITU) TelecommunicationStandardization Sector (ITU-T). The standard defines the procedures andprotocol by which network elements in the public switched telephonenetwork (PSTN) exchange information over a digital signaling network toeffect wireless (cellular) and wireline call setup, routing and control.

[0002] A softswitch is a software-based entity that provides callcontrol functionality. The various elements that make a softswitcharchitecture network include a call agent which is also known as a mediagateway controller or softswitch. The network also includes a mediagateway, a signaling gateway, a feature server, an applications server,a media server, and management, provisioning and billing interfaces.

[0003] The softswitch architecture does not replace an SS7 architecture.For example, when a person wants to setup a call from one location toanother location, the person picks up the phone at one location anddials a set of numbers. A local switch recognizes the call as a longdistance call, which then goes to a long haul exchange where it isrecognized as an out of state call. The call is then transferred to anational gateway for the other location. The call then has to make a hopto an intermediate gateway, which is located somewhere between the twolocations and finally the call goes through two or three switches beforeit connects to a local switch associated with the number. The role ofSS7, which does not use traditional trunks, is to ensure prior toactually setting up the call that there is a clear path from end to end.Only when there is sufficient resources is the call set-up.

[0004] The major difference between a softswitch architecture and atraditional architecture is that the call is not required to passthrough as many smaller switches. Today, when the person makes a trunkcall the person uses the whole trunk even though a smaller portion ofthe available bandwidth is required. On the other hand, with asoftswitch architecture, an Internet protocol (IP) connection betweenthe gateways of the two locations is established and a switching fabricbetween the two locations is in the form of fiber optic lines or otherform of trunk. There is no need to reserve trunks and set-up is notrequired. One only has to reserve the bandwidth that the call will need.

SUMMARY

[0005] The inventions discussed below relate to a call processingapproach that provides a distributed, open architecturetelecommunications environment for addressing the needs of carriers andservice providers in converging voice and data networks.

[0006] In one aspect, the invention is a method of call processing. Themethod includes passing, over a local area network, control signals froma centralized controller to each of a multiple of decentralizedprocessors. The method also includes for each of the multipleprocessors, in response to the control signals, executing decentralizedcall control functions.

[0007] Embodiments of this aspect of the invention may include one ormore of the following features. Passing, over a local network, controlsignals includes loading control data from an external device. Thecontrol data includes data associated with performing maintenancefunctions. The maintenance functions include centralized monitoring. Themaintenance functions include a redundancy failover. The method alsoincludes interfacing the distributed processors by tying to a set ofsoft switch protocols. The centralized controller is a mainframe.Passing control signals is performed using an Internet protocol. Themethod also includes associating at a physical layer addresses of thedistributed processors with physical locations. The method includesoverwriting default address with an internal address. Each of thedistributed processors is associated with at least one access device.Each of the distributed processors is associated with at least oneaccess device over a wide area network.

[0008] In another aspect, the invention is a call processing system. Thecall processing system includes a centralized controller to send controlsignals to multiple distributed processors. The system also includes alocal area network to couple the centralized controller to each of thedistributed processors to perform decentralized call processing.

[0009] Embodiments of this aspect of the invention may include one ormore of the following features. The control signals are associated withperforming maintenance functions. Each distributed processor has dataphysical layer addresses that are location based. Each distributedprocessor interface has a soft-switch architecture. Each distributedprocessor communicates over a wide area network to access gatewaydevices. The gateway devices include a voice over asynchronous transfermode gateway. The gateway devices include a voice over internet protocolgateway. Each distributed processor has another processor that serves asa redundant partner. Each processor has a software task. The softwaretask is an independent call-processing entity. The system also includesa packet manager interfacing with an interconnect controller. The packetmanager interfaces at least one of a server, a router or a firewall. Thesystem also includes an interconnect controller providing abi-directional interface between the centralized controller and thedistributed processors, the packet manager and signaling gateway. Thecentralized controller sends broadcast messages to control theprocessors. The centralized controller includes a local area networkcontrol and monitoring device and a call control device. The callcontrol device interfaces with telephony signaling network. Thetelephony signaling network is an SS7 network. The system also includesa packet manager interfacing with the centralized controller.

[0010] Executing decentralized call control functions in response tocontrol signals from a centralized controller provides numerousadvantages. In general, call control features (e.g., call waitingthree-way calling) as well as subscriber, billing, and failure controlinformation are provided by a number of decentralized processors, eachof which can operate independently and in parallel with otherprocessors. Concurrently, the centralized controller provides overallmanagement and maintenance of the individual processors. Using a numberof decentralized processors provides a substantial increase in theevent-processing capacity of the network while the centralizedcontroller provides stable and reliable management of the processors.

[0011] By managing the individual processors from a centralizedcontroller, modifications to call features as well as altogether newfeatures can be introduced or “rolled-out” on a network-wide basis. Forexample, software upgrades can be introduced from the central controllerwithout risk of disturbing legacy features that customers wish tomaintain. The decentralized processors are controlled by the centralizedcontroller to provide back-up in the event of failure by any of theprocessors. Such modifications and additions are transparent to thecustomer. The system architecture and operation allows customers tomigrate more smoothly to today's converged networks.

[0012] The system architecture is particularly well suited in allowingthe high quality and variety of voice services of real-time voicenetworks to be transferred to data networks, and conversely enables IPapplications to be used in the voice network. The open architecture isfully scaleable and offers flexibility by supporting existing legacysystems, while allowing the introduction of newer call feature services.

DESCRIPTION OF THE DRAWINGS

[0013]FIG. 1 is a block diagram of a multiservice switch architecture.

[0014]FIG. 2 is a block diagram of a media gateway controller and callfeature server.

[0015]FIG. 3 is a block diagram of a packet manager.

[0016]FIG. 4 is a block diagram of inter-connect controller (ICC).

[0017]FIG. 5 is a diagram of a side of a converter board.

[0018]FIG. 6 is a block diagram of an interconnection between ainter-connect controller and a network services processor.

[0019]FIG. 7 is a block diagram of local area network (LAN) components.

[0020]FIG. 8 is a block diagram of media control platform (MCP).

[0021]FIG. 9 is a diagram of a minimum MCP shelf configuration.

[0022]FIG. 10 is a diagram of a maximum MCP shelf configuration.

[0023]FIG. 11 is an MCT Communication Table.

[0024]FIG. 12 is a Command Distribution Table.

[0025]FIG. 13 is a table of an address conversion on MCP 28.

DETAILED DESCRIPTION

[0026] Referring to FIG. 1, a multiservice switch (MS) architecture 10includes a softswitch controller 12 for providing signaling and controlfunctions, a gateway 14 for providing trunk gateway functions, and anaccess platform 16 for providing line access functions. Softswitchcontroller 12, gateway 14 and access platform 16 are networked togetherwith a core packet network 18 with quality of services (QoS)characteristics to provide all services which include multi-media anddata and voice.

[0027] As will be described in greater detail below, softswitchcontroller 12 provides control inter-working between public switchedtelephone network (PSTN) and packet-based networks, and implements voiceservices and feature transparency between PSTN and packet networks.Since softswitch controller 12 interfaces different media, softswitchcontroller 12 uses different protocols in order to communicate with thedifferent media. For example, softswitch controller 12 uses a MediaGateway Control Protocol (MGCP), an ITU-T (InternationalTelecommunications Protocol) H.323 protocol, Bearer-Independent CallControl (BICC), Remote Authorization Dial-In User Service (RADIUS)protocol and SS7. MGCP is used by softswitch controller 12 to centrallycontrol voice over packet gateways and network access servers. The ITU-TH.323 protocol is a set of signaling protocols for the support of voiceor multimedia communication within a packet based network (e.g., IPnetworks). The ITU-T H.323 protocol covers the protocols necessary foroperation and for interconnection with circuit switched networks. BICCis the protocol used between softswitch controller 12 to exchange localinformation regarding call setup. RADIUS is the standardized protocolfor Internet access control. SS7 is the world-wide standard for commonchannel signaling in the network.

[0028] Gateway 14 bridges the gap between packet-based networks andPSTN. Gateway 14 is controlled by softswitch controller 12 and providesthe media stream conversion between a time division multiplex (TDM)network and Internet Protocol (IP) or from an asynchronous transfer mode(ATM) network.

[0029] Access platform 16 provides access technologies from existingPlain Old Telephone Service/integrated Services Digital Network(POTS)/(ISDN) to generic Digital Subscriber Lines (XDSL) and otherbroadband services such as Frame Relay ATM as well as Voice over IP(VoIP) access gateways.

[0030] Unlike a traditional switching architecture consisting ofsignaling and call control, trunk access, line access and a switchingfabric all residing in one box, MS architecture 10 provides all the samefunctions found in a traditional architecture, as well as others, butdistributes these functions over a network. Thus, softswitch controller12 performs the signaling and controlling functions, access platform 16and gateway 14 functionally perform the trunk/line access and QoS packetnetwork 16 performs the function of the switching fabric.

[0031] Many factors are considered when developing the systemarchitecture for softswitch controller 12. One of the most importantfactors which drives the architecture development is the requirementthat softswitch controller 12 support the full Class 5 feature set. Toaccomplish this goal, full advantage is taken of the existing, verystable Digital Switching System (EWSD) feature software. This re-use hasthe immediate advantage that the required features are already availablein a tested, stable environment. Therefore, a server architecture 20 forsoftswitch controller 12 fits within the framework that allows for thedevelopment of a platform which has minimal impact on the requiredfeature set. An additional critical factor to consider is the rate atwhich technology is constantly improving and evolving. Any serverarchitecture which is developed therefore, will use commerciallyavailable platforms (where possible) so that significant improvements inthroughput and capacity may be realized by upgrading the platforms asthe improved technology becomes available. Lastly, the call model andcapacity issues are incorporated into the architecture design.

[0032] Referring to FIG. 2, softswitch controller 12 has a serverarchitecture 20 which can be thought of as having seven functionalparts, namely, a Network Services Processor (NSP) 22, an Inter-ConnectController (ICC) 24, a Packet Manager (PM) 26, a set of distributedMedia Control Platforms (MCPs) 28, an Integrated Signaling Gateway (ISG)called a Signaling System Network Control(SSNC) 30 and lastly, aconnection medium which allows all of the functional blocks tocommunicate with one another. The connection medium is split into twoentities, namely, a first connection 32 between NSP 22 and ICC 24 and asecond connection 34 between ICC 24 and distributed platforms 28.

[0033] In this embodiment, architecture 20 supports 4,000,000 busy hourcall attempts (BHCA). However, for the purposes of call modelcalculation, architecture 20 can support up to 250,000 trunks. When amean holding time of 180 s/call is used for 250,000 trunks (125,000incoming and 125,000 outgoing) this equates to 2,500,000 BHCA (or 695calls/s).

[0034] A. Common Media

[0035] First connection 30 between NSP 22 and ICC 24 is an 8-bit serialinterface (proprietary) which mimics an input/output processor:messagebuffer (IOP:MB) to Message Buffer interface. This interface iscompletely realized in the hardware (HW). Second connection 34 isbetween ICC 24 and the system periphery (MCP 28, PM 26, and NSP 22).This connection is realized using a Fast Ethernet (100 MB/S) LANsegment. The EWSD HW based addressing algorithm will be converted to astandard IP based addressing scheme.

[0036] B. SSNC Overview

[0037] SSNC 30 performs the signaling gateway functionality. SSNC 30 isa multi-processor system consisting of a single shelf (minimumconfiguration) of HW. SSNC 30 is its own system with its own maintenancedevices disks and optical devices. It is “loosely coupled” to NSP 22 viaan ATM30 link and to the local area network. SSNC 30 performs the taskof terminating the SS7 from the network and converting the signalinginto server compatible messaging. SSNC 30 further controls the routingof messages to NSP 22 or media control tasks (MCTs). Further, SSNC 30will route SS7 messages from softswitch controller 12 to the network.SSNC 30 terminates pure SS7 links. In other embodiments, the SS7 linkswill be replaced by stream control transmission protocol (SCTP)associations. SSNC 30 consists of the following HW: a main processor:Stand Alone (MP:SA), an ATM Multiplexer (AMX), an ATM central clockgenerator (ACCG), an alarm indicator (ALI), link interface circuit(LIC), along with associated small computer system interface (SCSI)disks and optical drives. The MP:SA is the system master and performsthe control functionality such as OA&M, loading, for example. The AMXprovides the connectivity between system pieces, i.e., allowing all ofthe units to communicate with one another via a proprietary asynchronoustransfer mode (ATM) protocol called Internal Transport Protocol (ITP).The MP:DEP performs the Signaling Link Termination (SLT) functionality.It is responsible for the SS7 handling. The ACCG is the source of thesystem clock. The ALI provides the alarm interface for the system.Additionally, it provides the interface for the radio clock referencesignal (i.e., network reference). The LICs provide the termination forthe SS7 links. The LICs will in the future be replaced by MP:DEP-E(Ethernet) for Stream Control Transmission Protocol (SCTP) termination.

[0038] C. PM Overview

[0039] PM 26 provides the interface to the Media Gateway for the serverarchitecture 20 the incoming signaling is done via ISDN Signaling UserPart (SS7), BICC and MGCP messaging. The platform HW is realized using acommercially available Sun FT1800 fault tolerant system detailed below.Connection to softswitch controller 12 is done via redundant Ethernetpaths on the LAN. PM 26 is an external device which is not fullyintegrated into server architecture 20. PM 26 is totally decoupled fromsoftswitch controller 12 as far as any recovery, configuration, ormaintenance strategy.

[0040] There is a form of loose coupling which is realized by a periodicmessage sent from NSP 22 to PM 26 via each redundant LAN segment. PM 26responds to this message on each LAN side. The purpose of this messagingis two-fold in that it serves to inform NSP 22 that PM 26 is stillavailable and secondly, the message from NSP 22 to PM 26 contains theactive LAN side so that PM 26 knows which LAN side to use whentransmitting to NSP 22 and/or any other peripheral platform.

[0041] D. PM HW Configuration

[0042] The PM system configuration is a variant of previous PMconfigurations with specific modifications to support the required dualEthernet connection. This is the only PM modification required forcompatibility with the call feature server (CFS) architecture.

[0043] Referring to FIG. 3, the PM system configuration 60 consists of asingle rack of equipment and a free standing, local managementworkstation. PM hardware suite 60 includes one rack mounted SunMicrosystems Netra ft 1800 subsystem (−48 VDC) 62, two rack mountedGarrett DS880 10/100 Ethernet hubs (−48 VDC) 64, one rack mounted Cisco2611-DC access server (−48 VDC) 66, and one free standing SunMicrosystems Ultra 5 workstation (110 VAC) 68. Subsystem 62 is the corecomponent of PM 22 and is configured as follows in a PM Dual Processorsystem configuration: one main system chassis, two 300 MHz CPUSETS with512 MB memory (one per side), two hot plug 6 slot disk chassis (one perside), four 18 GB disk drives (two per side), two removable MediaModules with a compact disk read only memory (CDROM) and Digital AudioTape (DAT) tape drive (one per side), two 8 slot hot plug PeripheralComponent Interconnect (PCI) chassis (one per side), two Console, Alarm,Fan (CAF) modules (one per side) each with two Ethernet ports (net0/1),one console port, one Remote Control Port (RCP), one modem port, four10/100 Ethernet PCI cards (two per side) (two for softswitch Ethernet,two for dual attach EWSD Network manager (ENM) Ethernet), two 155 MB OC3ATM PCI cards (one per side), and four hot plug power modules (two perside). In other embodiments, the basic Dual Processor configuration maybe optionally upgraded to a quad processor configuration for increasedperformance.

[0044] Subsystem 62 is a hardware fault tolerant subsystem. This isachieved by the dual sided hardware architecture of subsystem 62 thatenables both sides to operate in lock-step I/O synchronization (combinedmode), and also independently (split mode). This architecture alsoprovides fault isolation and containment with respect to hardwarefailures within subsystem 62.

[0045] The configuration of subsystem 62 used in PM 26 is designed towithstand failures in a single hardware component. All electricalcomponents, CPUSETs, I/O devices, PCI buses are duplicated, and are hotreplaceable by design. Failure of a single I/O device (ATM card, LAPDi/f card, Ethernet card, disk, tape drive, etc), CPUSET, or power modulewill not bring the system down. Furthermore, failure of a single I/Odevice will typically not bring a side down.

[0046] Software faults do have the potential to bring the entire systemdown when operating in combined mode since the both sides willexperience the same fault due to the lockstep operation of subsystem 62.

[0047] A single Cisco Access Server provides a mechanism for terminatingserial port connections from Subsystem 62 and provides external accessto these serial ports via an Ethernet connection for maintenance andcontrol operations. These serial ports are: Side A console port, Side ARemote Control Processor (RCP), Side B console port and Side B RemoteControl Processor (RCP). Two (2) Ethernet 10/100 auto-sensing hubs areincluded in the PM system configuration to provide redundant externalnetwork connections and support for the PM's internal network. Allsubsystem 62 Ethernet connections are configured as dual attach Ethernetconnections (connected to side A and Side B with auto failover) yieldingfault tolerant Ethernet network connections except for the twosoftswitch Ethernet connections. The softswitch Ethernet connections donot require dual attach functionality since redundancy is handled by theOpEt software.

[0048] Workstation 68 is a standard Sun Microsystems off-the-shelfworkstation product. Workstation 68 functions as the local managementstation for controlling the PM frame during software installations,upgrades, and repair operations. A dial-up modem is also supported onworkstation 62 for emergency remote access.

[0049] E. NSP Overview

[0050] NSP 22 is realized utilizing the hardware of the EWSD CP113C. Thehardware is robust, stable, fault tolerant and provides a “ready-made”environment to ensure that the feature rich EWSD call processingsoftware will run without problems. The hardware consists of standardEWSD CP113C HW up to and including the input/output (I/O) interfaces.This includes base processors (BAP), call processors (CAP), commonmemory (CMY), bus for CMY (B:CMY), input/output controllers (IOCs) andinput/output processors (IOPs) and the existing storage media (MDD)issupported as well.

[0051] The role of NSP 22 is to provide the feature/Call processingprocess (CALLP) database. NSP 22 also performs the loading of necessarydata to the distributed MCPs 28 and perform those coordinated functionsnecessary to keep the system operational (e.g., maintenance, recovery,administration, alarming, etc.). The advantage of using the CP113Chardware is clear. All of the necessary functionality exists and can bere-used with a minimum set of changes (as opposed to are-implementation). One further advantage of this re-use is the factthat all of the existing operations support systems (OSS) can besupported.

[0052] F. ICC Overview

[0053] Referring to FIG. 4, ICC 24 is a multifunctional unit. ICC 24provides a bi-directional interface between NSP 22 and the distributedplatforms 28, PM 26, and Signaling Gateway 30. In addition to providingthe interface, it provides the protocol conversion between standard EWSDmessaging (i.e., message buffer unit/message channel (MBU/MCH) basedaddressing) and Ethernet Media Access Control (MAC) addressing(discussed in detail below), since the actual platform interconnect willbe provided via fast Ethernet (100 MB/s internal local area network(LAN) segment(s)). ICC 24 handles the routine test interface from NSP22. This is necessary to satisfy the hardware/software (HW/SW) interfacewhich requires the functional buffering/switching devices (switchingnetwork (SN) and message buffer (MB) from the EWSD architecture) to bepresent. Lastly, it supervises the LAN interface (i.e., reflect theconnection status of the distributed platforms 28 to NSP 26), detect anyLAN faults and report any faults to NSP 22.

[0054] ICC 24 performs inter-platform routing for any distributedplatform. Thus, whenever a peripheral platform (including devices: MCP28, PM 26, and Signaling Gateway 30) communicates with a second (ormultiple) peripheral platform(s), the message is sent to ICC 24 and ICC24 reroutes it to the required destination. This is necessary to offloadNSP 22 since the above mentioned messages would normally be routed viaNSP 22. This bypass provides NSP 22 with additional capacity. In otherembodiments, the devices communicate with one another directly and ICC24 merely monitors each device and informs the other devices of anystatus changes.

[0055] The ICC 24 has the following functional blocks. An interfaceboard 42 is a pure HW component which addresses the signaling interfacebetween CP113C IOP:MB, an 8-bit parallel interface, and ICC 24.Interface board 42 connects directly with a controller board 44 whichacts as a multiplexer. One controller board 44 supports up to eightinterface connections and therefore by extension, eight IOP:MBinterfaces. If additional IOP:MB interfaces are supported, for example,up to 7 are required to support 4,000,000 BHCA, then this isaccomplished by adding interface boards 42 (which support up to 4interfaces) and/or controller boards 44.

[0056] The next functional block is the application SW 46 itself.Application SW 46 communicates with the controller board via DirectMemory Access (DMA) (bi-directionally), so that NSP messages may bereceived and sent. Lastly, a LAN controller 48 provides the actualinterface to MCPs 28, PM 26, and Signaling Gateway 30. The applicationentity therefore provides the bi-directional connection path between NSP22 format messages and the Ethernet messages.

[0057] The ICC HW is realized by using a standard slot based 500 MHZPentium III (or better) CPU slotted into a passive backplane. TheInterface card HW 42 requires a standard Industry Standard Architecture(ISA) connection, while the Controller HW 44 uses a peripheral componentinterconnect (PCI) slot. The LAN controller(s) 48 also use standard PCIinterfaces.

[0058] G. ICC HW

[0059] Softswitch controller 12 development ICC 24 is a PC based system.It converts NSP 22 I/O system (IOP:MB) to the PCI-BUS standard which isused in a PC environment. Generic PC-boards can be used to furtherprocess NSP 22 data and send it via NIC to the LAN which connects allunits involved in the data exchange.

[0060] ICC 24 is housed in rack mountable case that holds the differentPC-boards to assemble ICC 24 functionality. Due to redundancy, two ICCs24 are needed. To connect both the ICC with NSP 22, the SPS frame isrequired. The frame contains converter boards and the necessary cablesto hook up the ICC with NSP 22.

[0061] There are 2 ICCs 24 each housed in 4U case with 12 slot passivebackplane. Each ICC 24 contains one Slot CPU, two NIC, two switchingperiphery simulator B board (SPSB) controller boards, two switchingperiphery simulator C board (SPSC) interface board, two switchingperiphery simulator D board (SPSD) port board, one SPS frame is withfour switching periphery simulator E board (SPSE) converter boards.

[0062] In other embodiments, each ICC 24 contains one Slot CPU, onenetwork interface card (NIC), one switching periphery simulator B board(SPSB) controller board, one SPSC interface board, one SPSD port board,one SPS frame with two SPSE converter boards.

[0063] The Slot CPU with a Pentium III, 1 GHz runs the control SW underWindows98/Linux. Currently 512 Mbyte system memory is sufficient toexecute the SW applications.

[0064] The LAN board (NIC) is the interface to the LAN which enablescommunication with the PM/PCU and the MCPs. This network interface cardis a commercial board which holds it's own CPU. An intelligent serveradapter suitable for this embodiment is the PRO/100 manufactured byIntel. The on-board CPU takes over a lot of load balancing and LANmaintenance tasks which will free up the PC-CPU for more importantduties.

[0065] The controller board (SPSB) communicates with the PC SW via busmaster DMA and with NSP 22 via the interface boards. The controllerboard contains a MP68040 with 25 Mhz bus clock, an interface to the PCmemory using DMA via PCI bus, a 32-bit interface to the outside of thePC realized with a 37-pin sub-d connector (10-PORT) for testing andcontrolling purpose, an interrupt input for the MP68040 (one pin of the37-pin sub-d connector), a clock, reset, grant, address and data bus tofour SPSC boards where the SPSB can control up to four SPSC which allowsthe connection of sixteen IOP:MB interfaces, a 256 Kbyte RAM, no waitstate access, and a 256 Kbyte Flash memory (2 wait state access whichholds the FW for the 68040 CPU).

[0066] The interface board (SPSC) has a connection with NSP 22. Theboard includes four interfaces to IOP:MB, two interfaces are accessiblevia 26-pin high density sub-d connector located on SPSC board. The othertwo interfaces need to be connected via two 26 pin ribbon cables withthe SPSD board. The board also includes a counter for central time stampwith a resolution of 1 us.

[0067] One board holds four IOP:MB interfaces which will be sufficientfor up to 60 k trunks. If more trunks are needed another interface boardis added so that 250 k trunks can be supported.

[0068] Port board (SPSD) serves as a port to the outside since only two26 high density (HD) sub-d connectors fit on board SPSC. The SPSChowever allows the connection of four IOP:MB and therefore the missingtwo connectors are placed onto SPSD. SPSD holds only passive components,two connectors for two 26 pin ribbon cables and two 26 HD sub-dconnectors.

[0069] SPS FRAME (SPSSF) is mounted in the ICC rack and holds up to 4converter boards (SPSE) which translate up to sixteen IOP:MB interfacesignals to/from TTL/bipolar. All necessary cables are connected betweenIOP:MBs, SPSSF and ICC 24 which creates a compact device.

[0070] CABLE (B) connects one IOP:MB interface of the ICC, with the SPSframe (SPSSF). It plugs via 1-SU SIPAC connector into the SPSSF backplane and with a 26-pin SUB-D connector into one IOP:MB interface on theICC. The SPSSF feeds the signals from cable (B) to SPSE which is used toexchange data/control information between the ICC and the IOP:MB.

[0071] CABLE (X) is a Standard cable between IOP:MB and MB. This cablehas a 1-SU SIPAC connector on both sides and connects the SPSSF with theIOP:MB.

[0072] Referring to FIG. 5, Converter board (SPSE) 80 supports fourIOP:MB interfaces and converts the signals between TTL and bipolar sinceICC 24 needs TTL signals and the IOP:MB uses bipolar signals. There aretwo light emitting diodes (LEDs) (green LED 82 a and red LED 82 b), twotoggle switches (reset switch 84 a and set switch 84 b), three switches(an address-0 switch 86 a, an address-1 switch 86 b and a power switch86 c) and one 37-pin connector 88 located on the front of SPSE. GreenLED 82 a indicates available power if lit and the red LED 82 b showsthat at least one request address from the IOP:MB is switched to ICC 24.Set toggle switch 84 b forces all request address (A0, A1, A2) of allfour IOP:MB interfaces to be switched over to the ICC, this has to bedone after every power on of SPSE. Reset toggle switch 84 a clears allregister on SPSE and no request will be sent to ICC 24, and is used fortest only.

[0073] The A1 and A0 switches select the board interface number (0,1,2,or 3) which can be traced by connecting the interface tracer (IFTR) to37-pin connector 88. A1 A0 interface number Down down 0 Down up 1 Updown 2 Up up 3

[0074] A 37-pin sub-d connector female is the interface for theIFTR-Tracer. Power switch 86 c turns the power on and off. The SPSEcontains a set of four DIP switches per IOP:MB interface which areswitched on for proper signal termination.

[0075] Referring to FIG. 6, each ICC 24 a and 24 b is a compact PCI(CPCI) based system. It comprises a generic CPU board with Intel PentiumIII CPU 70 a and 70 b with 1 Ghz, 512 Mbyte Memory and up to twointerface boards 74 a-b and 76 a-b for connecting with NSP 22. The twoICCs 24 a and 24 b are housed in one shelf with compact PCI back plane.Two Interface boards connect up to four IOP:MB from NSP 22 and one100Base-Tx Ethernet port. For example, board 74 a connects to IOP:MB 78c and port 79 c; board 76 a connects to IOP:MB 78 d and port 79 d; board74 b connects to IOP:MB 78 a and port 79 a: and board 76 b connects toIOP:MB 78 b and port 79 b.

[0076] H. Local Area Network Components

[0077] Referring to FIG. 7, the LAN is a 100Base-TX Ethernet thatinterconnects all system components. All units hooked up to an Ethernethub/switch, a hub is usable up to 1M BHCA and has to be replaced by aswitch for greater than 1M BHCA. A switch is used even for the 1M BHCAsystem, since the extra bandwidth offers a higher quality of service.

[0078] Two 100Base-TX Ethernets 92 a and 92 b are used for each ICC 24 aand 24 b to connect all units via LAN. The two LAN segments are neededto support enough bandwidth between the ICC and MCP 28. There are atleast 23 units hooked up to one LAN segment (ICC, PM/PCU, sixteen MCPs,four SCTPs, Router for OAM&P and SG). For redundancy reasons, fourindependent LAN segments are employed. (Two for side0 and two forside1).

[0079] I. MCP Overview

[0080] Referring to FIG. 8, MCP 28 consists of a slot based centralprocessing unit (CPU) (Pentium III 500 MHZ or better) in a backplane.MCP 28 provides a platform for media control functions, which work withthe software in NSP 22 to provide media control features. MCP Softwareis divided into the following two functions: Media Control Functions andMCP Manager Functions 50. Each MCP 28 supports up to 62 Media ControlTasks (MCTS) running simultaneously under a real-time operating system(VxWorks). Each MCT is an independent call-processing entity. EWSD LineTrunk Group (LTG) software is reused extensively to provide the MCTfunction.

[0081] MCP Manager Functions 50 are distributed across a messaging task52, software watchdog task 4, a MCT Loading & Startup Task 56, and a MCPmaintenance task 58.

[0082] Messaging task 52 is multi-functional. It provides the interfaceto the Ethernet for communication between all tasks on MCP 28 and NSP 22or other distributed platforms. It also provides an interface with ICC24 for maintenance of the LAN and the message channels associated withthe Media Control Tasks.

[0083] SW Watchdog task 54 is responsible for monitoring all MCP tasksto ensure that each task is running correctly. MCT Loading & StartupTask 56 provides an interface to NSP 22 for loading of MCT software. Itis also responsible for managing and manipulating the context associatedwith each MCT, and for generating each MCT task in its correct context.MCP Maintenance Task 58 performs general maintenance functions on MCP28, including handling reset requests from NSP 22, routine test andaudit functions, utilities and processing firmware upgrades. MCP ManagerFunctions are further explained below.

[0084] J. MCP Hardware Configuration

[0085] MCP 28 replaces the existing LTG hardware and software. MCP 28supports 62 Virtual LTG images under control of a commercial OperatingSystem (i.e., VxWorks) along with the necessary messaging and supporttasks. The MCP hardware requirements will support WM requirements andUS.

[0086] The Media Control Processor (MCP) hardware and Operating Systemis based on commercially available products. The overriding requirementfor the Hardware is that it be (US) Central Office ready or NEBS Level 3compliant. The key components are the MCP Processor Board, EthernetSwitch, Chassis/Backplane, and Rack.

[0087] Referring to FIGS. 9 and 10, the R1.0 minimum MCP shelfconfiguration has four 5-slot enclosures, one redundant pair of MCPs 28a and 28 b, and two Ethernet switches (for sides 0 & 1) 92 a and 92 b.The R1.0 maximum MCP shelf Configuration has four 5-slot enclosures,four redundant pairs of MCPs 28 a-h or eight MCPs and two Ethernetswitches (for sides 0 & 1) 92 a and 92 b.

[0088] 1. MCP Processor Board

[0089] The MCP Processor Board will plug into a passive Backplane. Itwill receive power and the board location (shelf/slot) from theBackplane, and all connectivity and communications is achieved throughthe Ethernet ports. It may be also possible to use a Backplane Ethernetbus. The processor on the board is a x86 because the ported code is inIntel assembly language.

[0090] The processor board (PB) is a single computing board (SBC)platform, single slot computer platform. The processor board has thefollowing characteristic. The PB Size fits into a chassis that fits intoan EWSD Innovations Rack (BW Type B). The PB pitch size or width is usedfor calculating the estimated heat dissipation, approximately 1 mm ofpitch/1 watt. Boards are hot swappable. The boards have a Intel (x86)processor and Cache size: Minimum size 256K at full speed.

[0091] PB has a high performance CPU/Bus/Memory having a CPU >500 MHzcore frequency, 133 MHz system bus frequency and a Highspeed SDRAM(e.g., 10 ns). The Memory size is 768 Mbytes to 1 Gbytes, in stepsexpandable.

[0092] PB has error detection and correction for memory. PB has flashmemory size of at least 32 Mbytes used as a boot source (i.e., no harddisk) and is field upgradable. Other features include, a HW watch-dog(2-stage: Stage 1—Soft, Stage 2—Hard), a HW Timer (1 ms; 100 msgranularity), BIOS Support; Boot from Flash (including board test anddiagnostics), Hard or Soft Reset Capability, Real-time OS Board SupportAvailable (e.g., VxWorks), low power dissipation less than 20 Watts andMTBF greater than 10,000 FIT (MTBF less than 11 years), and backwardcompatibility for next generation boards, (i.e., pin compatibility,reuse of existing shelf).

[0093] The SBC External Interface features include 2×10/100 Mbit/sEthernet interfaces (i.e., dual Ethernet ports integrated on processorboard), Cabling with rear accessible Interfaces, debug interfaces withFront access (e.g., RS-232, USB), board status visual indicators (FrontAccess, red/green LED's), and board reset push button (Front Access).

[0094] 2. Ethernet Switch Board

[0095] An Ethernet Switch is required over the use of a hub. The traffic(synchronization issue) requirements will begin to saturate the fastEthernet when 500 LTGs are supported. When more than 2,000 LTGs aresupported, the switch will become more important. The Ethernet SwitchBoard is an off-the shelf cPCI product.

[0096] The Ethernet Switch Board Type has a self-learning feature and 24ports with 10/100 Mbit/s each. 16 ports are connected via cabling (rearconnection, e.g., RJ 45) with the 16 processor boards and 8 ports areconnected via connectors (rear connection, e.g., RJ 45) for inter shelfconnection. The Ethernet board also has hot swappable boards, powerdissipation for a single slot board greater than 20 watts for a doubleslot board is less than 40 watts and MTBF less than 10,000 FIT (MTBFgreater than 11 years).

[0097] 3. Chassis/Backplane

[0098] The Shelf(Chassis) includes a Backplane and Power Supply.

[0099] The shelf or chassis will house the SBCs, Power supplies, and theEthernet Switch board, and will be mounted in a rack. The Shelf PowerSupply Type has redundant power supply (−60; −48 V) for 16 Pro+2 SwitchBoards per shelf, N+1 redundancy, hot swappable power supply boards, andMTBF less than 10,000 FIT (MTBF greater than 11 years).

[0100] The Shelf and Backplane Type is packaged has having ≧16 processorboards+2 Switch Boards+Power supply in one shelf. The Backplane is splitfor repair and replacement, a split Backplane solution will double thepower supplies required for redundancy. The Backplane has Shelf and Slotindication readable by the SBC for location identification.

[0101] The rack supports 4 shelves or greater per rack (7 ft rack),EWSD-mod rack size BW-B Rack, and has a rack power dissipation less than3.5 kW.

[0102] The following section describes the Shelf/Backplane and Rack,Single Computing Boards, and Building Practices required for the system.

[0103] The Shelf/Backplane provides power, a shelf and slot identifier,and pass environmental test as required by our customers (i.e., NEBSCertification). In order to support redundancy, repair, and upgradeprocedures the Backplane is split. It is possible to remove a faultyBackplane for repair without losing any stable calls in the system.Redundant Power Supplies are required for fault, upgrade, and repairsituations.

[0104] A minimum of 4 shelves fit into the Rack and the alarms and fusesare integrated into the Rack. The fans contribute heat dissipation andare incorporated into the shelf/rack configuration. The Backplane/Shelfcombination supports a minimum of 16 processor boards, redundant powersupplies, and an Ethernet Switch. Cabling is done at the rear of theshelf. The rack suitable for this embodiment is manufactured byInnovations Rack (BW Type B).

[0105] There will not be any disk on the SBC; an internal RAM-disk orflash memory will be used for booting the system.

[0106] The MCP boards communicate via a 100 Mbit Ethernet interface forinternal synchronization data and communications to the MBD-E. Theinternal LTG data synchronization is required for the LTG redundancyscheme, a fail-over design. In order to support the message throughputrequired for a 240K (or greater) trunk system it will be necessary toincorporate an Ethernet Switch, which will keep the synchronizationtraffic off of the communication connection to the MBD-E.

[0107] There are three configurations can be used for small, typical,and large system definitions. For a small configuration, two to fourMPCs 28, MCP 28 can be directly connected to the MBD-E platform. For atypical configuration, 240K trunks, a single stage Ethernet Switch canbe used. For a large configuration, greater than 240K trunks, a secondlevel of Ethernet Switches will be required. All the configurations areredundant for availability, upgrade, and repair.

[0108] The realtime operating system (OS) supports running dualoperating systems, full register save/restore on a context switch. TheOS has a full suite of off the shelf support packages to support thehardware bringup. (Board Support Packages).

[0109] K. System Redundacy

[0110] Softswitch controller 12 is a fully redundant, fault-tolerantsystem. NSP 22 is realized using the CP113C HW from the existing EWSDconfiguration. Since this is already a fault tolerant system, no extradevelopment is required to ensure redundancy in NSP 22. The ICC/LANredundancy is realized due to the fact that two copies of each exist(side 0 and side 1). A failure of one unit automatically causes aswitchover to the secondary unit (without any service interruption).This is handled via the Fault Analysis SW (FA:MB is adapted to handleICC) running on NSP 22. The LAN itself uses a “productive redundancy”concept. This means that both LAN sides are active but each carries halfthe traffic (this is accomplished with no additional development effortby using the standard LTG message channel distribution (i.e., each taskhas a different default active/standby side). If a LAN failure occurs,the switchover causes the remaining LAN to carry the full traffic load.MCP 28 itself is not a redundant platform, however, since the MCT SWsupports redundancy (LTGC(B) concept), it is possible to make each MCTredundant. This is realized by distributing the MCTs in such a way thateach task has a partner which runs on a different MCP. Thus, the failureof a single MCT results in its functionality being taken over by the“partner” board. The failure of a MCP board results in the switchover ofeach MCT being carried by that board. The SSNC redundancy is realized ata HW level but in a different manner than within NSP 22. Each unit(e.g., MPU) has a redundant partner. For example, MCPs 28 consist of twoMPUs which run micro-synchronously. This same concept applies to AMX,ACCG, ALI-B and LIC. The concept of a system half does not exist withinSSNC 30. The redundancy therefore is realized on a per unit basis.

[0111] L. MCP Detail

[0112] As explained above MCP Manager software 50 provides supportfunctions for the media control tasks that operate on the MCP. MessagingTask 52 provides the communication interface between MCP tasks and twoEthernet LAN interfaces 59 of MCP 28. All incoming Ethernet messages arerouted to Messaging Task 52. Messaging task 52 examines each message anddetermines the appropriate target task based on the encapsulated messageheader (Destination MBU, Destination MCH, Jobcode 1 and Jobcode 2).Interfaces in Messaging Task 52 allow other tasks to send messages outover the LAN. These interfaces perform address translation between therequested EWSD destination address (MBU/MCH) and a correspondingEthernet address. Messaging Task functions 52 are described in furtherdetail below.

[0113] Software Watchdog Task 54 monitors all the tasks that operate onthe MCP. The main function of SW Watchdog task 54 is to detect when atask has ceased to function properly due to a software error. When afailed task is detected, Software Watchdog 54 takes corrective actions,depending on the type of task that has failed.

[0114] MCP Maintenance Task 58 performs several functions that arerelated to the operation of the MCP platform. The main function of MCPMaintenance task 58 is to provide an interface to a CoordinationProcessor (CP) for configuration and testing, and to perform periodicmonitoring of MCP hardware. It also provides interfaces for utilitiesand for the MCP firmware upgrade function. The functions of MCPMaintenance task 58 are separated into three sub-tasks: a high priorityMaintenance task, a low-priority Maintenance task and abackground-testing task. The high priority task performs time criticalactivities such as fault reporting, configuration etc. The low prioritytask performs non-time critical functions such as upgrade and MCTpatching. The background-testing task executes at the lowest systempriority and performs functions such as routine testing and audits.

[0115] MCT Loading & Startup Task 56 is responsible for starting andmanaging the MCTs. It provides an interface to NSP 22 for loading andpatching MCT software. It also builds the context associated with eachMCT (data memory, descriptor tables etc.) and can generate or kill agiven MCP task.

[0116] In addition to the above task functions, there are severalsoftware functions that are performed, but which are not associated witha specific task. A system startup function initializes the MCP Managertasks 52, 54, 56 and 58, as well as all hardware and other resourcesused by the MCP Manager 50.

[0117] A context switching function loads and saves MCT contextinformation during task switches. This information is in addition tobasic context information that is saved by VxWorks. A timer functionprovides a periodic clock update to each MCT. An MCT Interface Functionsprovides a way to interface between the MCT and the MCP Managersoftware, via call gates. These are mainly used for message transmissionand reception in the MCT. A signal handling function provides a means todetect and recover from MCT exceptions detected through the normalVxWorks exception-handling mechanism. This replaces the interruptservice routines that handle exceptions within existing MCT software.

[0118] The following describe the actions required of the MCP Managertasks, in the context of the high-level functions that are performed onMCP 28. These include MCP initialization, MCP recovery andconfiguration, MCP operation, MCP messaging, fault detection, MCP Patchfunction, MCP upgrade, and MCP utilities.

[0119] The MCP Initialization includes MCP boot and VxWorks-start-up.During MCP Boot, at power on (or CPU reset) the BIOS (after the power-onself test is passed) invokes a routine called romInit. The romInitroutine disables interrupts, puts the boot type (cold/warm) on thestack, performs hardware-dependent initialization (such as clearingcaches and enabling DRAM), and branches to a romStart routine. TheromStart routine copies the code from ROM to RAM and executes a routineusrInit, which is just copied. The routine usrInit initializes alldefault interrupts, start the kernel and finally starts a “root task”(usrRoot), the first task running under the multitasking kernel. TheusrRoot routine initializes the memory pools, enables the HW watchdog,sets the system clock rate, connects the clock ISR, connects MCT SW INTISRs, announces the task-create/task-switching hook routines (to setupGDTR/IDTR/Debug registers at task create/task switching), flashes theRed LED, create the MSG-queues for all possible tasks (four MCP tasksand sixty-two MCT tasks) on the MCP and installs the Ethernet carddriver. Depending on a parameter (in the NVM1), one of the followingwill take place:

[0120] First, in a Bootp solution, usrRoot routine generates thebootload-task, that uses the bootp to retrieve the boot parameters andftp the load image from the Bootp-server to RAM. After the image isloaded, the bootload-task is deleted and the just loaded code (MCPManager code, routine MCPStart) is executed (see below).

[0121] Second, in a boot from flash solution, usrRoot checks to see if aroutine MCPStart is on flash. If yes, userRoot loads MCPStart from EPROMto RAM and executes it, otherwise it falls back to Bootp.

[0122] The routine MCPStart generates the following tasks: softwarewatchdog 54, messaging task 52, MCT code loading and start up task 56,the high priority MCP Maintenance task, the low priority MCP maintenancetask, and the background testing task. SW watchdog task 54 is generatedby the MCPStart routine. Its entry point is a routine called McpSwWD. Itallocates and initializes (erases) the WatchDog table for all possibletasks, except the SW watchdog itself (i.e., Messaging, MCT Code loadingand Startup, MCP Maintenance and n*Media Control tasks, n=62—this valuemay change, depending on the CPU performance—). After the WatchDog tableinitialization, the SW Watchdog Task 54 suspends itself (and will beawaken every 100 ms, “taskDelay”).

[0123] Messaging task 52 is generated by the MCPStart routine. Its entrypoint is the routine called McpMsgSt. It allocates and initializes(erases) the MCT Task Id⇄MBU/MCH conversion table and the Input/Outputqueues, programs the Ethernet card and starts the communication to NSP22 (i.e. sends SYN).

[0124] MCT Loading & Startup Task 56 is generated by the MCPStartroutine. Its entry point is the routine McpCode. It initializes (erases)an 8 MB RAM area for storage of the MCT code and a list of the MCT tasks(n entries, n=62). The MCT Loading & Startup Task 56 is then ready toreceive code-loading sequence from NSP 22.

[0125] MCT Maintenance Tasks 58 are generated by the MCPStart routinethrough the high priority maintenance task using the entry point routineMcpMtc. It allocates, initializes (erases) its memory, sends the messageMCPRESET Response to NSP 22 (on both LAN sides), generates the lowpriority and background test tasks, starts a periodic timer 100 ms (towake it up) and suspends itself with a call to msgQReceive routine.

[0126] The MCT tasks can be started only after the MCT code has beenloaded to RAM (from NSP 22). After the MCT code loading, theMCT-Code-loading-and-startup task, based on the GDT included in theMCT-code creates GDT0 . . . GDTn−1. The code selectors of each GDTremain the same but the data selectors are adjusted to point to theassociated data area of each MCT task. The stack selector is alsoadjusted to point to the physical address of the stack area assigned theMCT task.

[0127] The MCT-Code loading-and-startup task also calculates the totalMCT-memory size (MCT-code excluded) and allocates/initializes (erases) ndata areas for n MCT tasks.

[0128] The MCT-Code loading-and-startup Task calculates the stack sizeof the MCT task and the addresses of n stack areas of n MCT tasks. Notethat the stack areas physically reside in the MCT memory areas.

[0129] The MCT-Code loading-and-startup task converts the address of theMCT-entry point “conditional code loading” to the VxWorks format.

[0130] The MCT-Code loading-and-startup task 56 creates n*MCT tasks(n=62) with the stack area, stack size and MCT-entry point in VxWorksformat. The number of tasks is determined by the number of tasks forwhich the last code loading sequence was completed (number of tasks inthe broadcast or single code-loading sequence).

[0131] MCT-Code loading-and-startup task activates the MCT tasks, whichwere created in the previous step. The activated tasks are now ready forreceiving of the semi-permanent data from NSP 22.

[0132] MCP Recovery & Configuration has the following characteristicsfor the initial Start 2F. The initial condition is when MCP 28 is upwith at least one ACT MCT Task in NSP 22 database. At the beginning ofISTART2F NSP 22 sends the MCPTEST command (to MCP Maintenance Task 58)and the MCP respond with MCPTESTR. NSP 22 then sends command MCPRST(Data: FULL reset), that causes the board to reboot. After reboot, theSoftware Watchdog Task 54, Messaging Task 52, MCP Loading and Start UpTask 56 and Maintenance Task 58 are generated and the MCPRSTR message issent to NSP 22. After the command MCPLAN is sent from NSP 22 to MCP 28:Messaging Task 52, the following hand shaking sequence between NSP/ICCand the MCP Messaging/FW Boot tasks will take place: Collective Command(CCM):CHON/CHAR(load info=load program, LTG info:conditionalloading)/CCM:CHAC/CHAS/CCM:RCVR (Data: SRL22 with RAMformatting)/CCM:CHON/CHAR (load info=load program, state=conditionalloading).

[0133] Afterwards NSP 22 sends all MCT Code segments to the FW BootTask, which stores them in the MCT code area that was allocated duringMCP initialization after code loading, the MCT Loading & Startup taskstores the MCH channel statuses and the indication of “Send TERE=YES”,TERE data to the interface areas (see 4.4.1.1) for all 62 MCT tasks.These data are the input for the MCT entry point MCT_Init routine. MCTLoading & Startup task also initializes and activates the MCT tasks thatare in the collective command list. The activated MCT Tasks send TEREmessages to NSP 22 and become active after the receiving semi permanentdata and LTAC sequence.

[0134] MCP Recovery & Configuration has the following characteristicsfor the Initial Start 2R. The Initial condition is when the MCP is upwith at least one ACT MCT Task in NSP 22 database. At the beginning ofISTART2R NSP 22 sends the MCPTEST command and the MCP responds withMCPTESTR. NSP 22 then sends command MCPRST (Data: Soft reset), thatcauses the SW Watchdog task to delete all MCT-Tasks, if any. Then theacknowledgment MCPRSTR is sent to NSP 22, which, in turn, sends commandMCPLAN to the Messaging task 52 of MCP 28. Afterwards, the followinghand shaking sequence between NSP/ICC and the MCP Messaging/FW Boottasks will take place: Collective Command (CCM):CHON/ CHAR(data=same asISTART2F case)/CCM:CHAC/CHAS/CM:RCVR (data:SRL22 w/o RAMformatting)/CCM:CHON/CHAR (data=same as ISTART2F case)

[0135] From this point on, the bring up is the same as in the ISTART2Fcase, except the MCT-code checksum is verified and is loaded only if thechecksum test fails (but the MCT SW Boot code is always loaded).

[0136] MCP Recovery & Configuration has the following characteristicsfor the Initial Start 1, Initial Start 2. The initial condition is whenthe MCP is up with at least one ACT MCT Task in NSP 22 database. At thebeginning of ISTART1 or ISTART2, NSP 22 sends the MCPTEST command andMCP 28 responds with MCPTESTR. NSP 22 then sends command MCPRST (Data:INIT). This command resets only the messaging task memory but the MCTTasks are not deleted. MCP 28 then sends the acknowledgment MCTRSTR toNSP 22, which, in turn, sends command MCPLAN to the MCP:Messaging task.Afterwards, the following hand shaking sequence between NSP/ICC and theMCT Tasks will take place:

[0137] Collective Command (CCM): CHON/CHAR (info=no program loading,state=init)/CCM:CHAC/CHAS/CM:RCVR (data: SRL21)/PRAC/CM:CHAC/CHAS.

[0138] The MCT Tasks whose OST is ACT in NSP 22 database will receiveLTAC commands and are configured into service. The MCT tasks, which werein service before ISTART1/ISTART2 but now have both message channelsoff, will be suspended by the Messaging task For a MCP Configurationthat has a Single MCP Configuration with loading (CONF MCP, RESET=YES),the Initial condition is when MCP is MBL or UNA. Upon receiving of MMLcommand CONF MCP to ACT with RESET=YES, NSP 22 sends the MCPTEST commandand the MCP responds with MCPTESTR. NSP 22 then sends command MCPRSTwith Data=Full Reset to the MCP Maintenance task, result in a platformreboot and initialization. At the end of the initialization, theresponse MCPRSTR is sent to NSP 22. NSP 22 sends command MCPLAN to theMCP, selects the first “to be configured” MCT and tries to bring it up.

[0139] The first MCT task bring-up begins with the code loading into theMCP. The MCT code is downloaded with the following sequence: CHON/CHAR(data: same as in ISTART2Fcase)/CHAC/CHAS/RCVR(PRL22 with RAMformatting)/CHON/CHAR(data:same asabove)/CHAC/CHAS/CLAC/LODAP/PAREN/code loading commands/CHECK/TERE.

[0140] The received code is stored in one common shared RAM area, asdone in ISTART2F case. After the code is completely loaded, the MCTLoading & Startup task builds the GDT and allocates data areas for theMCT task that is being configured and initializes them. Then itactivates the (being configured) MCT Task, which sets up its ownenvironment (such as set up the register DS, ES, SS, SP . . . . ),initializes its semi-permanent and transient memory, sends the TestResult message to NSP 22 (only on the ACT LAN side). Then, after thesequence CHAC/CHAS/CLAC, NSP 22 continues to bring up the MCT task bysending the semi permanent data to MCP 28. The MCP Messaging Taskspasses the semi-permanent data to the MCT task, which finally becomesactive after receiving a sequence of LTACs commands.

[0141] After the first MCT task is brought up, NSP 22 will sequentiallybring up the remaining “to be configured” MCT tasks. The bring up startswith the hand shaking between the MCT Startup Task and NSP 22: CHON/CHAR(Data: Load Information=load program, state=Conditionalloading)/CHAC/CHAS/RCVR(PRL22 w/o RAMformatting)/CHON/CHAC/CHAS/CLAC/LODAP/PAREN/code loadingcommands/CHECK/TERE.

[0142] After the hand shaking sequence, NSP 22 starts loading code tothe MCP. With the exception of the MCT's software boot code, all othercode segments are loaded only if the checksum examination fails. Thenthe GDT and data areas are allocated for the current MCT Task, as wasdone for the first task. This task is then activated and is configuredinto service after the data loading as described in the section above.

[0143] With a single MCP Configuration without loading (CONF MCP,RESET=NO), the Initial Condition is the MCP is MBL or UNA. Uponreceiving of MML command CONF MCP to ACT with RESET=NO, NSP 22 sends theMCPTEST command and the MCP responds with MCPTESTR. NSP 22 then sendscommand MCPRST with data=Init (to maintenance task 56 of MCP 28). Thiscommand causes the Messaging task's database to be reset and the messageMCPRSTR to be sent to NSP 22. Next, NSP 22 sends command MCPLAN to theMCP and then sequentially brings all MCT tasks with the Operation Status(OST) ACT in its database and brings it up with the sequence: CHON/CHAR(with data: same as Initial_Start_(—)1)/CHAC/CHAS/CLAC/RCVR(Data=FA:Level_(—)21)/PRAC/LTAC/LTAS.

[0144] In a Single MCT configuration, the command CONFLTGCTL is acceptedby NSP 22. However, the parameter (LOAD=YES/NO) is no longer allowed.Depending on the loading flag in NSP 22 data base, one of the followingscan occur:

[0145] In the MCT configuration with code loading, the initial conditionis when MCP is active with at least one MBL/UNA MCT task in itsdatabase. The MML command CONFLTGCTL is entered to configure a MCT fromMBL to ACT. The loading flag in NSP 22 data base is for some reason set(this flag should never set but for some reason, due to a SW error, itcould remain set) The following sequence will take place: CHON/CHAR(with data: load info:load/no load, Init/Load—depending on the MCTstate—)/CHAC/CHAS/CLAC/RCVR(Data=FA:PRL22)/CHON/CHAR/CHAC/CHAS/CLAC/LODAP/PAREN/code loadingcommands/CHECK/TERE

[0146] Upon receiving the RCVR (FA:PRL22)1 the MCPcode-loading-and-Startup task deleted the configured MCT task. The codeloaded from NSP 22 is accepted only if the MCT code has never loadedbefore or the MCT code is identical with the stored MCT code. Otherwise,the platform will re-boot. If the code loading is successful, the MCTtask will be generated.

[0147] For single MCT configuration without code loading, the initialcondition is when MCP is active with at least one MBL/UNA MCT task inits database. The MML command CONFLTGCTL is entered to configure a MCTfrom MBL to ACT. The loading flag in NSP 22 database is not set. Thefollowing sequence will take place: CHON/CHAR (with data: loadinfo:load/no load, Init/Load—depending on the MCTstate—)/CHAC/CHAS/CLAC/RCVR (Data=FA:PRL21) . . . .

[0148] In a normal case, i.e., the MCT code is already loaded, the MCTtask is activated and will be brought up. If the MCT code is not yetloaded, the CHAR data will contain “forced loading.” If the MCT wasactive at some time prior to the configuration to MBL, and is now beingre-activated, then the MCT will respond to the CP indicating that it canbe activated without code/data loading. Alternately, if the MCT wasnever activated before, then the MCT startup task will respondindicating that conditional code loading and data loading are necessary.

[0149] Each MCT task has its own GDT, IDT and breakpoints. Whenswitching tasks, the VxWorks OS has to save/ restore the GDTR, IDTR andDebug Registers of the old/new task. In addition, some interfacevariables need to be updated, such as increment/deletion of counters,that can be used by the MCT task to detect “Program runtime too long”,or to make a determination whether or not it can prematurely terminateits round-robin time slice. To achieve this, a routine (MCPCtxSw) isprovided to the VxWorks OS (taskSwitchHookAdd) at platforminitialization. The routine MCPCtxSw will be invoked at every taskswitch, which will ensure that each task is running with its own GDT,IDT and breakpoints.

[0150] The tasks on the MCP platform are running under a mixture ofpreemptive priority and round-robin scheduling algorithm. The MCP tasks(MCT tasks excluded) below are listed from high priority to low priorityorder:

[0151] Software watchdog: performs its function and then sleeps for 100ms with taskDelay

[0152] Messaging task: wake up only if there are message(s) in one ofits message queues

[0153] MCT Code loading and Start up task: wake up only if there aremessage(s) in its input queue

[0154] MCP High priority Maintenance task: wake up only if there aremessage in its input queue. Since this task also performs periodic tasks(such as check the memory leaking (i.e., hung resources) or control theLEDs), it starts a 100 ms timer to wake itself up.

[0155] all MCT tasks have the same priority, which is lower than thepriority of any of the tasks of the group above. The MCT tasks run withround-robin scheduling. Each task gets a time slice of 1 ms. A MCT taskcan prematurely finish its time slice if its has nothing to do, i.e.,its task queue is empty. In this case, an MCT audit program is invoked,that runs a few steps and then suspends the MCT task until a message isqueued in its queue.

[0156] MCP low priority Maintenance task runs with priority just lowerthan the MCTs (e.g., patching, upgrade & burn flash in the background).

[0157] MCP Background Testing Task runs with the lowest priority(audits, routine test etc.) Standard VxWorks interrupt handlers are usedfor most exceptions and for all external interrupt sources. A new MCPspecific exception handler replaces the Stack Fault exception handler.In addition, the platform timer interrupt is configured specifically forMCP/MCT operation.

[0158] The periodicity of a platform timer is set to 1 ms during VxWorksstartup. The usrClock routine is called on each interrupt. It informsthe VxWorks OS that the timer expired and updates the MCP common clock(every 4 ms) that are used (read only) by the MCT timer managementtasks.

[0159] Looking at the stack Fault Exception, the default VxWorks stackfault exception does not execute a task switch, and so is incapable orrecovering from a stack fault. Instead, a new exception handler is usedto allow recovery from stack faults in the MCTs. This exception handleris allocated its own Task State Segment and stack. When a stack faultoccurs, the exception handler first determines whether the faultoccurred within a MCT or in the general VxWorks context (kernel or otherMCP tasks). If the fault occurred within the general VxWorks context,then the platform is restarted since this represents a non-recoverableerror. However, if the exception occurred within a MCT, then the taskstate of the MCT is modified so that it resumes execution at theexisting stack fault recovery software within the MCT. The exceptionhandler also rebuilds the MCT stack so that it can resume operationcorrectly. Note that all interrupts on the VxWorks platform are disabledfor the duration of the stack fault exception handler.

[0160] The ability of a MCT to recover from processor exceptions areretained on the MCP. In order to accomplish this, MCP software receivesexception notifications from the operating system and actively repairsand restores these failed MCTs. This is done by the use of SignalHandlers.

[0161] Each MCT registers a signal handler for all the standardprocessor exceptions. When an exception occurs, the failed MCT issuspended by the operating system and the corresponding signal handleris invoked. It is not possible for this signal handler to repair thefailed MCT due to OS limitations, so this signal handler notifies asignal handler running under the MCT Startup task.

[0162] The MCT Startup Signal handler uses data passed within the signalto restart the failed MCT. The execution point of the MCT is modified tobegin execution at the MCT recovery code that corresponds to theexception. In addition, operands are added to the stack to provide thesame interface as is expected by MCT software. Finally, the failed MCTis restarted using the taskResume( ) facility of the operating system.Note that this logic is also applied for “debug” exceptions, with themodification that the code execution point is the MCT debug exceptionhandler instead of MCT recovery code.

[0163] The MCTs need to interface to certain VxWorks services. Since theMCTs operate in 16-bit mode and are separately linked, this interfacecannot be implemented via a direct “call”. Instead, an indirectinterface is used through “Call Gates”.

[0164] On activation of the MCTs, a reserved descriptor entry in the MCTGDT is configured to represent a call gate. When the MCT invokes thiscall gate, it will be redirected to execute a procedure within theVxWorks image, whose address has been populated in the call gatedescriptor. A translation from 16-bit to 32-bit code segments will alsotake place. Note that although the call gate performs 16-bit to 32-bittranslation of the code segment, the stack and other data segmentregisters remain as they were when executing on the MCT. Consequently,the procedure invoked by the call-gate first saves the existingenvironment and then set-up a new VxWorks compatible environment.Further VxWorks services can then be invoked.

[0165] The call gate interface is used by the MCT to invoke the servicesto receive one or more messages from the MCT message queue and/or tosend a message to another MCP task or out on the LAN. Parameters for thecall gate interface are passed using shared memory between the MCTmaking the call and the call gate software. This memory is part of theMCT image, but can be referenced and modified from the VxWorks addressspace.

[0166] The required call gate descriptor is built by the MCT Startuptask. The actual call gate function is provided as a separate MCPplatform module.

[0167] Each MCT is notified when a fixed interval of time has expired.The Timer Function detects this time period and provides the necessaryinterface to the MCTs. The following functions are implemented:Interface with the VxWorks operating system for timer interruptnotification; and when a predefined number of timer interrupts occur,increment global time counter (MCP_CLOCK) to reflect passage of time.

[0168] MCP_CLOCK is located within the MCT address space, at apre-defined label. This data is shared across all MCTs, so that it isnot necessary to update each task's data individually.

[0169] The value in MCP_CLOCK is used by the MCTs to calculate elapsedtime. Refer to the “MCT Software” section for details on this mechanism.

[0170] With this mechanism, the minimum granularity of MCP_CLOCK isdependent on the granularity of the VxWorks timer interrupt. However,MCT timers will still be limited to 100 ms granularity due to thelatency of the MCT round-robin scheduling scheme. Due to schedulingconsiderations, the periodic VxWorks clock will be set to fire every 1ms. In order to preserve the existing MCT clock intervals, MCP_CLOCKwill be incremented every 4 ms, by the VxWorks clock interrupt handler.

[0171] A periodic notification is sent to all MCTs every 100 ms. Thisnotification is used to “wake-up” MCTs that have no messages pending intheir message queues, and are blocked. The notification is necessary sothat the MCTs can updated their timers and process any internal jobs.

[0172] The global MCP_CLOCK variable is defined at a fixed label withinthe MCT address space. This is necessary so that the MCTs can refer tothis label within their linked load. MCT_CLOCK is defined as “Read Only”within MCT address space.

[0173] When activating a MCT, a layer is necessary between the startuptask and the actual MCT software. This layer is implemented in C andallows registration of the MCT with the operating system for functionssuch as Signal Handling or Message Queues. It also allows for a standard‘C’ entry-point into the MCT which simplifies MCT startup. At the end ofthe MCT startup layer, the actual MCT code is invoked via aninter-segment jump.

[0174] As with any processing platform, the MCP may encounter “overload”conditions during its normal operation. MCP Overload can be classifiedas a memory (or other resource) overload, a message input/outputoverload, an MCP Isolation or a CPU overload. Each type of overload isdetected and reported to NSP 22 via the new MCP_STAF message. Thismessage includes data such as the overload type, overload level, andtime of overload entry. In addition, steps are taken to attempt toreduce the overload condition, by reducing the traffic rate on the MCP.When overload ends, NSP 22 is notified again using a MCP_STAF. Thesefunctions are implemented in the high-priority MCP Maintenance Task andare described below.

[0175] Maintenance task 58 is responsible for general platformmaintenance of the MCP. This includes fault detection, configuration,recovery and testing. Maintenance task 58 is split into two sub-tasks—alow-priority task and a high-priority task. The overload function isimplemented in the high-priority task, since it is a time criticalfunction.

[0176] In order to detect MCP Overload, Maintenance Task 58 areperiodically monitored all resources that affect each type of overload.

[0177] For Memory Overload detection, Maintenance Task 58 performs aperiodic check of the remaining available memory in the dynamic memoryallocation pool. When this memory reaches a certain threshold (25%available for example), then it can be assumed that the MCP is runningout of memory due to system demands and MCP overload is initiated.

[0178] For Message Output Overload, Maintenance Task 58 performs aperiodic check of the queue depths of the Messaging Task 52 and theEthernet driver interface. If these queues fill up to a certainthreshold (80% for example), then it can be assumed that the MCP is notable to handle the current output message rate and MCP overload isinitiated.

[0179] For Message Input Overload, Maintenance Task 58 performs aperiodic check of the queue depths of the input queues of each MCT onthe MCP. If the average queue depth reaches a certain threshold (80% forexample), then it can be assumed that the MCP is cannot cope with thecurrent input message rate, and MCP overload is initiated.

[0180] For MCP Isolation, this type of overload is detected by theMessaging Task 52, when both LAN interfaces are determined to be faulty.When this occurs, Maintenance Task 58 is notified, so that it can setthe MCP overload level appropriately.

[0181] For CPU Overload, if the MCP CPU is overloaded, then each MCTwill receive insufficient run-time. This will be detected by the MCTsthrough the “Task Queue Overload” mechanism, and will be reported to NSP22. No actions are necessary in Maintenance Task 58 for this type ofoverload detection.

[0182] Once MCP overload has been detected, Maintenance Task 58 sends aMCP_STAF to NSP 22 to indicate the overload condition, and type ofoverload. Maintenance task 58 then sets a global “MCP Overload”indicator, which can be read by all the MCTs. This indicator will causethe MCTs to enter a local overload condition. Under these conditions,the rate of new MCT traffic will be reduced, which also reduces thecurrent MCP overload level. Only 1 overload level is seen to benecessary at this time.

[0183] After overload has been detected, Maintenance Task 58 continuesto monitor the overload condition in order to determine when normaloperation can be resumed. Normal operation is only resumed when thedepleted resource has returned to normal levels. This threshold is setso that a level of “hysteresis” is built-in to the overloadmechanism—i.e., the threshold for normal operation is significantlylower than the threshold for overload detection. This will ensure thatthe MCP does not oscillate constantly between overload and non-overloadstates.

[0184] In some situations, it is possible for software errors to lead tospurious overload conditions. For example, a memory leak could lead to“Memory Overload”. In order to avoid a permanent degradation of servicein such situations, Maintenance Task 56 monitors the duration of a giventype of overload. If this duration exceeds a certain limit (30 minutesfor example), then a platform reset is executed. This will allow theredundant MCP to take over and provide a better level of service. Aglobal data item is necessary to indicate MCP overload. This data isreadable from each MCT. The MCP provides a replacement for the 4 mstimer interrupt that is used by MCT software.

[0185] The MCP provides functionality for sending and receiving thefollowing message types over the Ethernet LAN interface:

[0186] 1. Commands and Messages between MCTs and the CP

[0187] 2. Reports between MCTs

[0188] 3. Messages between the Packet Manager and MCTs

[0189] 4. Incoming and outgoing signaling requests to the signalinggateway

[0190] The Messaging functionality of the MCP is divided into 2 parts:Platform Functions and LAN Functions. Platform functions provideinterfaces to all the MCP tasks, including the call control tasks, forthe purpose of message sending and receiving. They also handle messagechannel maintenance and distribution of incoming messages, includingbroadcast or collective distributions.

[0191] LAN functions provide the interface between the PlatformFunctions and the two Ethernet cards of the MCP. They handle translationbetween EWSD MBU/MCH destinations and Ethernet MAC addresses. They alsohandle maintenance of the LAN interfaces, and make routing decisionsregarding the LAN side to be used for certain classes of outgoingmessages.

[0192] Platform functions provide interfaces to all the MCP tasks,including the Media Control Tasks, for the purpose of message sending,receiving and distribution. The Messaging Task also provides the MCPwith its message channel maintenance function.

[0193] The MCP Messaging Task provides tasks running on the MCP with theability to transmit messages to other platforms in the network.Interfaces are provided through “Call Gates” in the MCT task's softwareat the point where message transmission is required. The Messaging Taskdefines procedures called by through the call gates to read message datafrom the task's output buffer. The Messaging Task then writes themessage to an output queue for transmission across the LAN (see LANfunctions for further details).

[0194] Referring to FIGS. 11 and 12, the MCP's Messaging Task receivesincoming messages from the LAN, determines their destination, and writesthe data to the destination task's receive buffer and/or processes thecommand if appropriate. The Messaging Task maintains two tables 100, 200used for routing messages called a MCT Communication Table 100 and aCommand Distribution Table 200.

[0195] MCT Communications Table 100 has twelve columns. The columnsinclude an MCT number 105, an MCT task ID 110, an own MBU (side 0) 120,Own MBU (Side 1) 125, a own MCH 130, a Peripheral Assignment Own(Own/partner) 135, a channel status (on/off) for each channel 140, apartner MBU (Side 0) 145, partner MBU (Side 1) 155, Part MCH 155 and aperiphery assignment partner (own/partner) 160.

[0196] Command Distribution Table 200 includes three columns. A firstcolumn 210 records Job Code 1, a second column records destination tasktype 220 and a third column record 210 the “message preprocessingroutine” 210 “Msg. Preprocessing Routine” column 230 tells MessagingTask 52 that this command contains information used by the MessagingTask. For instance, in the case of C:LTAC, Messaging Task 52 will lookinto the command and update its MCT Communication Table 100 with thePeriphery Assignment 135 information contained in the command.

[0197] The MCT messages are routed based on MBU/MCH numbers and TaskStatus (active/not active) 115. Messaging Task 52 uses MCT CommunicationTable 100 to determine which MCT the incoming message is destined for(via MBU/MCH) and if it's available to receive the message (by TaskStatus 115). After Messaging Task 52 determines the incoming message isdestined for a MCT and that task is active, the incoming data is storedin a receive buffer reserved only for that task. Messaging Task 52increments a ‘write’ counter for each message written to the MCT'sbuffer. This count tells the MCT task that it has one or more messageswaiting and should execute a read of the buffer.

[0198] Certain MCT messages do not have a MBU/MCH associated with them.Examples are MBCHON and all collective or broadcast commands. For suchcommands, a special header field is examined to determine the relativeMCT number(s) for which the message is destined. The MCT number is thenused to derive the specific MCT task that should receive the message.

[0199] The MCP tasks themselves also receive platform Task Messages(e.g., SW Watchdog, Boot, Startup, etc.) over the LAN, directly from NSP22. These messages are distinguished by the Messaging Task based on thetarget MBU/MCH. Each MCP is allocated a fixed address that correspondsto the first MCT position on the MCP (0-1, 1-1, 2-1 etc.). Such messagesare routed to the appropriate platform task, based on the receivedJC1/JC2 combination.

[0200] In certain cases, namely Maintenance and Recovery, commandscurrently handled by classic MCT software are routed to designatedplatform tasks running on the board. Before a message is distributed viaMBU/MCH lookup, Messaging Task 52 examines the JC1 of the message. Ifthe incoming command is of a ‘special’ type (RCVR, LOAD, etc.) anddestined for a platform-task, the message is copied to that task'sreceive buffer for processing.

[0201] The following is a Message-Distribution Summary:

[0202] 1. Reads message from its dedicated input queue

[0203] 2. Determines if message is an incoming message (from the LAN)and need to be distributed.

[0204] 3. If message is an incoming message, determines message type,based on target MBU/MCH—either MCP message or MCT message.

[0205] 4. If MCP message, use Job Code 1/Job Code 2 (JC1/JC2) to routemessage to correct platform task. JC1/JC2 of MCH maintenance messagesare directly processed by the messaging task. END.

[0206] 5. For MCT messages, use message header information to determinerelative MCT or MCTs for which message is intended.

[0207] 6. Get associated ‘Destination Task ID’ from Command DistributionTable using relative MCT(s) index(es).

[0208] 7. If the target MCT is not created or not active, route messageto MCT Startup Task. END

[0209] 8. If MCT is created and active, check JC1/JC2 to see if messageshould be redirected to platform task anyway (Code loading messagesetc.). If redirection required, send message to appropriate task. END.

[0210] 9. If target MCT created and active, check if preprocessingrequired i.e., Msg. Preprocessing Routine not null.

[0211] 10. If preprocessing required, calls routine specified. Afterpreprocessing finished, or if preprocessing not required, resumes withnext step.

[0212] 11. Copy message to target MCT message queue. END Messaging Task52 contains logic to intercept and redirect outgoing reports if they aredestined for an MCT running on its platform. Messaging Task 52 examineseach outgoing message's destination MBU/MCH number for a correspondingtask entry in its ‘MCT Communication Table’ 200. If it finds a match,and that task's periphery assignment is set to own, then the report iscopied to that MCT task's input buffer. Alternately, if the destinationMBU/MCH is found in a task's partner MBU/MCH entry, and thecorresponding partner-periphery assignment is set to partner, then thereport is also redirected and 1 s copied to that task's input buffer.

[0213] In order to distribute incoming commands and messages to the MCT,Messaging Task 52 maintains a table associating each Media Control TaskID with a unique MBU/MCH combination along with its associated channeland task status information. When Messaging Task 52 receives a messageand its JC1 indicates it is of the channel maintenance type, thecorresponding task entry in the table is updated accordingly. If thetask table does not contain an entry with the received MBU/MCHcombination, the message is forwarded to the MCT Startup task forfurther processing.

[0214] When the MCP's Messaging Task 52 detects an incoming MBCHONcommand, it reads the channel bitmap contained in the message andupdates any corresponding entries in the MCT Communication Table with an‘ON’ indication. The command is then forwarded to the Startup task forfurther processing.

[0215] CHOFF: When Messaging Task 52 detects an incoming Channel-Offcommand, the corresponding channel status entry for that channel isupdated (turned off). If both channels for a given MCT are turned off,then that task is suspended until the C:CHON is received. Furthercommands received for a task on a message channel which has been turnedoff are discarded. Send requests from a task for a channel which hasbeen turned off are also discarded.

[0216] ADINF: Before forwarding the Address Information Command to theMCT, the Messaging Task extracts address related information from thecommand and updates its MCT Communication Table 100.

[0217] The Messaging Task 52 reads Periphery Assignment information fromthe LTG Active command (LTAC), updates the corresponding element of itstable, and forwards the command to the MCT.

[0218] The MCP uses dual Ethernet cards to interface with the LAN. TheMessaging Task provides an interface to the device drivers of the twoLAN cards. The LAN device drivers are provided with the VxWorksoperating system. The drivers directly interface with the VxWorksNetwork daemon when incoming messages are received. Outgoing messagesare directly sent using driver interfaces.

[0219] Since the softswitch does not use a TCP/IP stack for internalcommunication, it is necessary to trap incoming Ethernet messages beforethey are delivered to the protocol stack. This is done using the“Etherhook” interfaces provided by VxWorks. These interfaces willprovide the raw incoming packets to the Messaging Task.

[0220] Incoming frames from other softswitch platforms are assumed to beusing the standard Ethernet header (not IEEE 802.3). Messaging Task 52distinguishes between Ethernet and 802.3 type frames using the 2 byte“Type” field. In addition, Messaging Task 52 also determines whether thepacket is using internal softswitch Ethernet protocol or is a realTCP/IP packet. This can also be done using the “Type” field of thepacket. A special value will be used for packets that encapsulate asoftswitch internal message, in order to distinguish them from IPpackets or other packets on the LAN. Packets using the internal protocolare queued to the Messaging Task input queues. Other packets arereturned unchanged for processing by the TCP/IP stack. For securityreasons, the Messaging Task verifies the source MAC address beforeaccepting packets that use the internal softswitch protocol. All suchpackets have source MAC addresses within the internal LAN.

[0221] When sending outgoing messages, the Messaging Task uses driverspecific interfaces to output one or more messages. Outgoing messagesare always sent with the standard Ethernet frame header, and thesoftswitch protocol indicator in the “Type” field. Care is taken toensure that the driver is not overloaded with message sending requests.The interface with the driver is examined to determine the maximum sendrequests that can be processed at one time. Message send requests thatexceed this threshold is queued to a retransmit queue by the MessagingTask for sending at a later time. Messages on the retransmit queue aresent first on any subsequent attempts to output messages to the driver.In addition, a periodic 100 ms timer is used to trigger retransmit ofmessages on this queue.

[0222] In summary, the Ethernet interface consists of an “Etherhook”interface for incoming packets, with filtering of softswitch specificmessages; a Message Send interface to be used by the Platform portion ofthe Messaging Task where the parameters include the destination MBU/MCHaddress and desired LAN side; a Message Queuing function to be used ifthe target driver is busy; and a periodic message re-send function toattempt retransmission of queued messages.

[0223] Referring to FIG. 13, Messaging Task 52 performs address aconversion to convert internal Message Buffer Unit (MBU)/ MessageChannel (MCH) addresses into external Ethernet MAC addresses. Theseconversions are only necessary when sending messages out over theEthernet LAN. For incoming messages, the MAC address need only bestripped off.

[0224] A table 300 shows the conversions that are necessary. Table 300has three main columns. A first column 305 stores a message type, thesecond column stores a destination address, and a third column 309stores a set of MAC addresses as two columns, a LAN Side 0 column 311and a LAN side 1 column 313.

[0225] From table 300, it can be seen that for most outgoing messages,the target MAC address is fixed to ICC 24, Packet Manager or IntegratedSignaling Gateway (ISG), regardless of the source MCT MBU/MCH.

[0226] Synch Channel messages require additional address conversion,because they are delivered directly to the target MCP. The DestinationMBU/MCH of the target MCT are converted into the MAC address of MCP 28that hosts this task. This conversion is implemented by converting thetarget MBU/MCH into a MCT number, consisting of TSG & LTG. This can thenbe converted into a host MCP number, using the standard mapping ofTSG/LTG to MCP 28. In future releases, the address conversion asdescribed for Synch Channel messages may also be used for routing ofreports between MCTs on different MCPs.

[0227] The entire address conversion function as described above areimplemented in Messaging Task 52.

[0228] MCP 28 uses two separate Ethernet interfaces for communication.Each interface is connected to its own LAN and ICC side. Incomingmessages can arrive over either LAN interface, and are processedregardless of which interface the message was received on. Outgoingmessages are selectively transmitted on a specific LAN side. The correctLAN side is selected by the Messaging Task during the transmission ofthe message. The selection is based on rules.

[0229] One rule is that messages from a MCT to NSP 22 or other MCTs aresent on the LAN side corresponding to the source task's “Active” messagechannel. This information is provided to the LAN interface function bythe Platform interface.

[0230] Another rule is that messages to NSP 22 from Platform Tasks canbe sent on either LAN interface. Since these messages could be sentunder different statuses of MCP 28 (initialization, failure etc.), theMessaging Task allows the platform tasks to specify a target LAN side(Side 0, Side 1, Both sides etc.).

[0231] A third rule is that messages to the Packet Manager are sent oneither LAN side as specified in the “MCP LAN” command received from NSP22. This information is provided to the Messaging Task by NSP 22 onstartup, and following any changes in connectivity with either the PM.The MCP LAN command indicates whether LAN side 0, LAN side 1 or both LANsides could be used for PM communication.

[0232] A fourth rule is that synch channel messages can be sent oneither LAN interface. The Messaging task attempts to use the LAN sidecorresponding to the source MCTs “Active” message channel. If this pathto the partner MCP is faulty, then the other LAN side are used instead(the Messaging task maintains a status for the path to the partner MCPover each LAN side—see “Fault Detection”).

[0233] There is a potential for lost messages, since the Ethernet isused as the transport protocol within the softswitch. This is because nolow-level “layer-2” acknowledgement mechanism is provided. This is not aproblem for messaging between the media control tasks and otherplatforms, because all such messaging is already supervised at theapplication layer. However, it is considered when implementing newmessage interfaces to MCP software. Such interfaces implement their ownsupervision mechanisms.

[0234] As described earlier, it is possible for the Ethernet driver tobe overloaded with message send requests. If this occurs andretransmission is not possible after 200 ms, then the messages arediscarded and an error counter incremented to indicate lost messages. Ifthis is a permanent condition, then the ICC will detect loss of this LANinterface due to loss of the periodic FLAGS responses, and takeappropriate actions.

[0235] When sending Synch Channel messages, it is possible for there tobe no path between MCP 28 and its partner. In this situation, synchchannel messages are discarded. An error counter are incremented toindicate lost messages. It may also be desirable to record the messagedata for debugging purposes.

[0236] Address conversion is performed based on the assumption that allunits know all the MAC and MBU/MCH addresses within the system. Ifinvalid addresses of one type or another are encountered, then thecorresponding messages are discarded, and counters incremented toindicate lost messages. It may also be desirable to record the messagedata for debugging purposes.

[0237] In certain situations, the point-to-point communication pathbetween the MCP and its partner MCP or the Packet Manager may beunavailable due to double-failures of LAN interfaces. Handling of thisscenario is described under the “MCP Fault Detection” section.

[0238] Data structures are implemented to support these LAN functions.The structure include a message retransmit queue, an address translationtable, a synch Channel address translation table, an error statisticcounters for lost messages with specific counters for the various errortypes and for incoming and outgoing directions, and a storage for theLAN side to be used for PM communication.

[0239] MCP detects and reports failures of a single media control task,specifically due to infinite loop conditions, failures of any of the MCPmanager tasks, hardware faults, detected by periodic routine testing,software Faults, detected by individual tasks, complete failure andrestart of the platform, and Media Control Software corruption. Failuresof the MCTs or other platform tasks are detected by the SoftwareWatchdog Task. Hardware failures or corruption of MCT software aredetected by Maintenance Task 58. MCP Reset is detected through messageinterfaces and supervision between MCP 28 and the ICC. Software faultscan be detected by any of the MCP Manager tasks, but are reported via aninterface in Maintenance Task 58.

[0240] In addition to the above platform specific failures, interfacesare also provided on MCP 28 for detection of faults on the LAN, and toverify the paths between NSP 22 and MCP, between MCP and partner MCP andbetween MCP and Packet Manager.

[0241] The following describes the implementation of the troubledetection, isolation and notification functions provided on MCP 28.

[0242] Software watchdog task 54 is responsible for supervising the MCTsand all other tasks on MCP 28. It is the central point of softwarefailure detection on the call-control platform. In order to provide thisfunction, the software watchdog task creates and maintains a datastructure (Watchdog Table) with entries for each possible task, providesan interface to allow each task to update its Watchdog Table Entry every100 ms, detects when a given task has failed to update its WatchdogTable Entry for a minimum of 200 ms, and triggers the hardware watchdogon MCP 28 to indicate that MCP software is still operational. TheSoftware Watchdog function supervises Media control tasks, MessagingTask, MCT Loading & Startup Task, MCP Maintenance Task and MCP UpgradeTask.

[0243] During normal operation, the software watchdog task monitors itsWatchdog Table to determine whether a given task has failed or beensuspended by the operating system. The watchdog task uses operatingsystem interfaces to determine when tasks block on resources, or go into“PENDING” states, so that they are not erroneously marked as failed.

[0244] When a failure of a task has been detected, the software watchdogtask is responsible for restarting the failed task, and generating anappropriate failure indication to the CP. These actions are dependent onthe type of task failure, and are described below.

[0245] If a media control task fails to update its watchdog table entry,then the task is assumed to be operating in an infinite loop. The taskis terminated and re-started by the software watchdog task, via aninterface to the MCP Loading & Startup task. This will cause the failedMCT to be terminated and a new incarnation started. The new mediacontrol task will begin execution at the point where semi-permanent dataloading is expected to begin. This will have the effect of putting theMCT through a Level 2.1 recovery.

[0246] The indication of a task failure is passed on to MCT Loading &Startup task, which then restarts the MCT, with special inputparameters. These parameters cause the MCT to generate a STAF (StandardFailure) message to NSP 22, with a fault indicator of “1.2 Recovery”.This will cause NSP 22 to initiate a switchover (if possible), andrecover the call control task with data reload. A new recovery errorcode will be used to indicate that the software watchdog task detectedthe failure.

[0247] Software faults are also possible in any of the VxWorks platformtasks. If one of these tasks fails to update its watchdog table entry,then it is assumed that the task has been suspended by the VxWorksoperating system. When this condition is detected, the software watchdoginitiates a reset of the entire platform (less severe fault actions arepossible, but they would leave the possibility of hung resources in theVxWorks operating system). NSP 22 is notified of this failure as part ofthe normal platform restart sequence (see later sub-section forMessaging Task fault detection), as well as via a MCP_STAF message.

[0248] Failure of the software watchdog task itself is detected by ahardware dependent watchdog function. The hardware watchdog resets everyiteration of the Software Watchdog task. Failure to perform thisfunction results in a reset of the entire platform. NSP 22 is notifiedof this failure as part of the normal platform restart sequence (seelater sub-section for Messaging Task fault detection).

[0249] The Software Watchdog task provides a data structure—the WatchdogTable, that can be used to monitor all the MCP tasks. This structure isaccessible by all software components, and is protected by semaphores toavoid read/write conflicts during access by the software watchdog tasksor any of the supervised tasks. The watchdog table includes a Task ID, aWatchdog Counter (incremented by tasks to indicate they are alive) andBlock Flag (indicator that task is in a blocking mode and are notsupervised).

[0250] Messaging Task 52 provides the interface to the Ethernet LAN forMCP 28. In the context of Fault Detection, this task provides amechanism for notifying NSP 22 when the entire MCP is restarted, amechanism for notifying NSP 22 when MCP 28 is faulty, and can no longersupport call-control functions, an interface for supervision of EthernetLAN from the ICC, and a mechanism for detecting mismatch conditions forLAN connectivity between MCP and partner MCP or MCP and Packet Manager.

[0251] MCP 28 may be restarted for any one of the following reasons:timeout of hardware watchdog, failure of platform task detected bysoftware watchdog task, initial Startup of MCP 28 or NSP 22 requestedrestart on ISTART2F. MCP 28 does not keep any history across a restart.Consequently, NSP 22 is notified that the platform has performed areset, so that appropriate fault actions can be taken. In order toaccomplish this, a special message (“SYN”) is sent to both planes of theICC when the Messaging Task is first started. The SYN providesnotification to the ICC that a restart has occurred on a certainplatform. On receipt of the SYN, the ICC will report message channelerrors for any channels that may still be marked as ‘in use’.

[0252] NSP 22 is notified if hardware faults are detected on MCP 28,resulting in the inability to support call-control functions. This isimplemented in Messaging Task 52 by providing an interface that allowsother platform tasks to trigger sending of the “SYN” message. Thisinterface will be used mainly by the MCP Maintenance Task.

[0253] ICC 24 supervises the Ethernet LAN. In order to provide quickdetection of failures on the LAN, the ICC will send special “FLAGS”messages every 100 ms to all MCPs on the LAN. The Messaging Task on MCP28 provides the following functions to complete the LAN supervisioninterface. First, Messaging Task receive the FLAGS message from ICC 24and all other MCPs. Second, it generate a response to the FLAGS messagefrom ICC 24, in order to notify the ICC that the corresponding LANinterface on the source MCP is working. Third, it processes data in theFLAGS message to determine connectivity to other MCPs over the same LANside (the FLAGS message contains a bitmap with the current state of theMCP—ICC connections). This data is used to determine the path to betaken for synch channel messages to the partner MCP.

[0254] Fourth, the Messaging Task supervises FLAGS reception from ICC24. Failure to receive FLAGS for a fixed period of time results in theLAN interface being declared as faulty, and the sending of all furthermessages on the redundant LAN side.

[0255] Messages sent from MCP 28 to the Packet manager or to the partnerMCP are delivered “point-to-point”. Consequently, it is necessary forMCP 28 to be aware of the connection availability of the target platformon either of the two available LAN sides, and to select the appropriateLAN side for communication.

[0256] For MCP—PM connectivity, on initial startup of MCP 28, NSP 22notifies MCP 28 of connectivity to the Packet Manager using the MCP_LANcommand. This command provides the available LAN interfaces that can beused for communication with the packet manager. The MCP_LAN command isresent if faults cause a change in the PM connection availability. Thisinformation is used by MCP 28 to select the appropriate LAN side for MCPto PM messages.

[0257] In certain situations, faults may cause MCP 28 and PM 26 to havemismatched connections. MCP 28 may only be able to use LAN side 0 fortransmission, but PM 26 may only be able to receive messages on LANside 1. In such situations, MCP 28 reports a fault to NSP 22 via theMCPSTAF interface (for notification) and then fail the platform usingthe “SYN” interface.

[0258] For MCP—Partner MCP Connectivity during normal “duplex”operation, each MCP needs to communicate with its partner MCP fortransmission of Synch Channel messages. These messages are also sent“point-to-point” and require the MCPs to be aware of the connectionstate of the target MCP. As described under “Ethernet Supervision” thisinformation is obtained by monitoring the “FLAGS” messages from ICC 24.

[0259] In certain situations, faults may cause MCP 28 and partner MCP tohave mismatched connections. MCP 28 may only be able to use LAN side 0for transmission or reception while the partner MCP may only be able touse LAN side 1. Such a situation is analogous to the existing “SynchChannel Failure” state of real hardware MCTs. When this occurs, one ofthe MCPs fails so that a switchover of MCTs can occur. Since both MCPsshould not fail, and cannot coordinate their failure due to lack ofcommunication interfaces, the lower-number MCP assumes the role of the“failing MCP” and the high-number MCP remains in operation. Failure ofthe low-number MCP is reported to NSP 22 using the MCPSTAF interface(for notification) followed by the “SYN” interface to trigger MCPconfiguration.

[0260] If both LAN interfaces of an MCP are found to be faulty (no FLAGSreceived), then the Messaging task takes steps to prevent the loss ofmessages. This is done by interfacing with Maintenance Task 58 totrigger MCP overload. This will in-turn trigger overload conditions inthe MCTs which will cause each MCT to discard unnecessarycall-processing messages, but preserve critical messages in their owninternal queues. When communication has been restored, Messaging Task 52clears the overload condition to allow sending of the buffered messages.

[0261] Messaging Task 52 maintains data on connectivity with other MCPsover the two LAN interfaces. This data will be updated by the FLAGSmessage sequence, and is used in determining the LAN on which SynchChannel messages will be sent.

[0262] In order to support trouble isolation and notification,Maintenance Task 58 provides an interface to NSP 22 for recovery,configuration and test; an interface to NSP 22 for verification of MCPload version information; background hardware test functions; backgroundverification of call-control software integrity; and software faultreporting.

[0263] Some functions of maintenance task 58 are background maintenancefunctions, which do not interfere with normal call-processing functionsof the MCTs. Consequently, Maintenance Task 56 functions 50 areseparated into three tasks: a high-priority maintenance task, alow-priority maintenance task and a background routine test task. Thelow-priority task performs non-time critical functions such as firmwareupgrade or patching. The background test task performs routine testingand audit functions that execute at the lowest system priority. Thehigh-priority task is reserved for processing time-critical functionssuch as MCP configuration and recovery.

[0264] MCP 28 provides an interface to NSP 22 for the purpose ofexecuting different reset levels of the platform. This interface is usedduring System Recovery and MCP configuration, to ensure that MCP 28reaches a known state prior to activation. The interface is implementedusing new commands and messages (MCPRESET and MCPRESETR) between NSP 22and Maintenance Task 58. The use of this interface is described indetail in the “MCP Recovery and Configuration Section”. Since thisfunction is time-critical (responses is sent to NSP 22), this functionis implemented in the high-priority maintenance task.

[0265] Maintenance Task 58 also provides an interface for testing thecommunication path from NSP 22 to MCP 28, and to verify that the MCPplatform software is operating correctly. This interface is used duringsystem recovery, MCP configuration into service and MCP testing. Theinterface consists of a new command (MCPTEST) which is sent by NSP 22 toMaintenance task 58 on the target MCP. Maintenance task 58 processesthis command and responds with a new message (MCPTESTR) which indicatesan MCP Fault Status (No Faults or Faults Detected), a MCP Fault Type(Hardware Fault, Software Fault, Overload) and an MCT Status. The MCPstatus has a Bbitmap representing sixty-two media control tasks,indicating whether each task is currently “active” or “inactive”. An“active” MCT is one that is being actively scheduled by VxWorks. An“inactive” MCT is one for which no instance has been created on MCP 28.

[0266] Maintenance Task 58 also provides an interface for load versionverification. This information is included in the MCPTESTR response toNSP 22.

[0267] Although the MCP software operates on a commercial platform,certain hardware test functions are possible. Maintenance Task 58performs these functions in the background, in an attempt to detecthardware errors. This function is limited to the verification of MCPmemory where memory verification is done by executing iterativeread/write/read operations on the entire MCP memory range.

[0268] If MCP hardware failures occur, Maintenance Task 58 notifies NSP22 that it is unable to support any media control functions. Restart ofMCP 28 in this situation is not desirable, because MCP 28 would loseinformation about its hardware failure, and would attempt to resumeservice if asked to do so by NSP 22.

[0269] When a hardware fault is detected, Maintenance Task 56 marks MCP28 as faulty, and trigger sending of the “SYN” message to both planes ofICC 24, via Messaging Task 52. This will cause NSP 22 to fail MCP 28 andits associated media control tasks. A MCP_STAF message are also sent toNSP 22 to indicate a hardware fault. This message is for informationpurposes only, and will not trigger any actions on NSP 22. Reception ofall future “MCPTEST” commands from NSP 22 results in a “MCPTESTR”message with the MCP status marked as “faulty”. This background testfunction can be executed at low traffic times, and is implemented in thebackground-testing task. When a fault is detected, a message is sent tothe high-priority task for the purpose of notifying NSP 22.

[0270] Maintenance task 52 provides an interface for reporting ofsoftware errors from individual MCP Manager tasks. Software errors areclassified as “Minor” and “Major”. Minor software errors results in aMCP_STAF message being sent to NSP 22, and error data logging. Errordata is logged in a special section of the MCP flash memory. This dataincludes error notebook information from MCTs, if relevant. Majorsoftware errors result in a MCP_STAF message, data logging, and a resetof MCP 28. This interface can be used for reporting of failures such asMemory Exhaustion, Data corruption, etc. Notification of software errorsis time critical so this function is provided by the high-prioritymaintenance task.

[0271] A single software image is shared by all the media control tasks.In order to verify that one of the tasks has not corrupted this image,Maintenance Task 58 performs a periodic background checksum verificationof this image. If the image is found to be faulty, then this tasktriggers a restart of the entire MCP. NSP 22 is notified of this eventas part of the normal platform restart sequence, and via a MCP_STAFmessage.

[0272] This audit is a low-traffic activity and is performed by thebackground-testing task. When a fault is detected, a message is sent tothe high-priority maintenance task in order to notify NSP 22.

[0273] Maintenance Task 58 defines data to store the current MCP faultstatus. This status is initialized to “No Faults” on startup of MCP 28.In addition, data is also defined to store the current MCP loadinformation. A special region of MCP flash memory is allocated forlogging of software errors.

[0274] When operating on MCP 28, patching of the MCTs is coordinated toavoid accidental corruption of a MCTs execution environment by anotherMCT which is applying a patch. Patch coordination is implemented by thelow-priority Maintenance Task. When a patch is received by a MCT, itperforms all actions in preparation of applying the patch, except theactual patch write to memory. Instead of this step, the MCT invokes theMCP Patch Function by sending a message to the low priority maintenancetask. No response is sent to NSP 22. The low priority maintenance taskonly runs when all the MCTs have reached an “idle” state and are blockedon their message queues. This ensures that the MCTs are in “patch safe”code. When the patch message is received by the low priority maintenancetask, it first executes a “task lock” function to prevent the MCTs fromexecuting while the patch is being incorporated. It then updates the MCTcode with the patch (contents taken from a shared memory buffer) andupdates the corresponding code checksum values. It also notifies thebackground testing task of the change in code checksum. After the patchhas been incorporated, a message is sent to the MCT to trigger aresponse to NSP 22 and normal scheduling is resumed.

[0275] The software images that will be maintained on MCP 28, innon-volatile memory include Boot Software, Current MCP Load Image, andBackup MCP Load Image. Boot software is an enhancement of the defaultVxWorks BootRom. It contains the minimum operating system functionalitythat is necessary to initialize MCP hardware, and access the MCPnon-volatile memory device. Boot software is always started on MCPreset. It is responsible for selecting the appropriate MCP Load image tostart, based on header information within the MCP load files. TheCurrent MCP Load image contains all the MCP software as well as allVxWorks operating system functionality necessary for MCP 28.

[0276] Of the three loads described above, only the Current & Backuploads can be field-upgraded. The Boot Software is never field-upgraded.It can be upgraded only by rebooting MCP 28 from floppy disk, andre-initializing the boot area of the MCP non-volatile storage device.

[0277] Load management of the MCP software versions is performed on theIntegrated Management System (IMS). Software on this platform providesinterfaces to ICC 24 and MCP 28 for version query and on-demand loading.

[0278] Within MCP 28, the MCP Upgrade Task handles upgrade of MCPsoftware. Upgrade of MCP 28 can be triggered through the following twointerfaces: NSP during MCP activation (System Recovery or Configuration)and IMS on demand. Regardless of the interface used, MCP upgradeincludes three actions: version checking, downloading of a new image,and reset and activation of the new Image.

[0279] MCP Upgrade is triggered by NSP 22 when a MCP is restored intoservice, either due to System Recovery or MCP Configuration, NSP 22requests a version check of MCP 28 software using the Command MCPSW. Onreceiving this command, the MCP Upgrade task initiates a query to theIMS, in order to determine the official current version of available MCPsoftware. If the version on the IMS is the same as the CURRENT MCPsoftware image, then a message MCPSWR is returned to NSP 22 indicatingthat no upgrade of NSP 22 is required.

[0280] If the current MCP software version does not match that on theIMS, then NSP 22 the MSPSWR message is returned indicating the mismatchand the need for upgrade. MCP 28 then requests download of the newversion from the IMS. During the download, NSP 22 queries MCP 28regarding the progress of the download using the MSPSW command. The MCPupgrade task responds with the MSPSWR message that includes a percentageof loading that has been completed.

[0281] When the entire load has been downloaded, the upgrade task waitsfor a final MCPSW query command from NSP 22 and responds with 100%complete in the MCPSWR. MCP 28 is then reset to activate the new load.Following activation of the new load, NSP 22 repeats the version checkstep, which in this case matches the version on the IMS. If theactivation of the new load fails for any reason, then NSP 22 aborts theMCP activation at this point.

[0282] MCP Upgrade is triggered by the IMS. The IMS provides an operatorinterface that can be used to query the current version of MCP software,and to initiate an upgrade of either the Current or Backup MCP loadversions. This interface uses the BootP protocol. The MCP upgrade taskinterfaces with the VxWorks TCP/IP stack to provide this interface. Notethat upgrade of MCP 28 from the IMS is only initiated when MCP 28 isout-of-service.

[0283] Software tools provide integrated utility software used duringdevelopment, testing, and debugging. Software tools suitable for thisembodiment include Wind River's VxWorks and Tornado Tool Kits. Availableutility functions include a graphical debugger allowing users to watchexpressions, variables, and register values, and set breakpoints as wellas a logic analyzer for real-time software. In addition, the developeris given flexibility to build targeted debugging and trace functions or‘shells’ within the VxWorks environment. Access to MCP 28 is providedthrough an external v24 interface allowing for onsite or remote access.

[0284] The utilities provided for task level debugging include datadisplay and modification, variable watching, and breakpoints. Theseutilities are integrated within the VxWorks operating system. Loggingand tracing functions are implemented to trap and display message datacoming into and leaving MCP 28.

[0285] Still other embodiments are written within the scope of theclaims.

What is claimed is:
 1. A method of call processing, comprising: passing,over a local area network, control signals from a centralized controllerto each of a plurality of decentralized processors, each of theplurality of decentralized processors, in response to the controlsignals, executing decentralized call control functions.
 2. The methodof claim 1, wherein passing, over a local network, control signalscomprises loading control data from an external device.
 3. The method ofclaim 2, wherein the control data includes data associated withperforming maintenance functions.
 4. The method of claim 3, wherein themaintenance functions include centralized monitoring.
 5. The method ofclaim 3, wherein the maintenance functions include a redundancyfailover.
 6. The method of claim 3, further comprising interfacing thedistributed processors by tying to a set of soft switch protocols. 7.The method of claim 1, wherein the controller is a mainframe.
 8. Themethod of claim 1, wherein passing control signals is performed using anInternet protocol.
 9. The method of claim 1, further comprisingassociating at a physical layer addresses of the distributed processorswith physical locations.
 10. The method of claim 9, further comprisingoverwriting default address with an internal address.
 11. The method ofclaim 1, wherein each of the distributed processors is associated withat least one access device.
 12. The method of claim 11, wherein each ofthe distributed processors is associated with at least one access deviceover a wide area network.
 13. A call processing system comprising: acentralized controller to send control signals to a plurality ofdistributed processors, a local area network to couple the centralizedcontroller to each of the plurality of distributed processors to performdecentralized call processing.
 14. The system of claim 13, wherein thecontrol signals are associated with performing maintenance functions.15. The system of claim 13, wherein each distributed processor has dataphysical layer addresses that are location based.
 16. The system ofclaim 13, wherein each distributed processor interface has a soft-switcharchitecture.
 17. The system of claim 13, wherein each distributedprocessor communicates over a wide area network to access gatewaydevices.
 18. The system of claim 17, wherein the gateway devices includea voice over asynchronous transfer mode gateway.
 19. The system of claim17, wherein the gateway devices include a voice over internet protocolgateway.
 20. The system of claim 13, wherein each distributed processorhas another processor that serves as a redundant partner.
 21. The systemof claim 13, wherein each processor has a software task.
 22. The systemof claim 21, wherein the software task is an independent call-processingentity.
 23. The system of claim 13, further comprising a packet managerinterfacing with an interconnect controller.
 24. The system of claim 23,wherein the packet manager interfaces at least one of a server, a routeror a firewall.
 25. The system of claim 24, further comprising aninterconnect controller providing a bidirectional interface between thecontroller and the distributed processors, the packet manager andsignaling gateway
 26. The system of claim 25, wherein the centralizedcontroller sends broadcast messages to control the processors.
 27. Thesystem of claim 13, wherein the centralized controller includes a localarea network control and monitoring device and a call control device.28. The system of claim 27, wherein the call control device interfaceswith telephony signaling network.
 29. The system of claim 28, whereinthe telephony signaling network is an SS7 network.
 30. The system ofclaim 13, further comprising a packet manager interfacing with thecentralized controller.